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Abstract 

Functional Reactive Programming (FRP) is an approach to the de¬ 
velopment of reactive systems which provides a pure functional in¬ 
terface, but which may be implemented as an abstraction of an im¬ 
perative event-driven layer. FRP systems typically provide a model 
of behaviours (total time-indexed values, implemented as pull sys¬ 
tems) and event sources (partial time-indexed values, implemented 
as push systems). In this paper, we investigate a type system for 
event-driven FRP programs which provide liveness guarantees, that 
is every input event is guaranteed to generate an output event. We 
show that FRP can be implemented on top of a model of sets and 
relations, and that the isomorphism between event sources and be¬ 
haviours corresponds to the isomorphism between relations and 
set-valued functions. We then implement sets and relations using a 
model of continuations using the usual double-negation CPS trans¬ 
form. The implementation of behaviours as pull systems based on 
futures, and of event sources as push systems based on the observer 
pattern, thus arises from first principles. We also discuss a Java im¬ 
plementation of the FRP model. 

Categories and Subject Descriptors D.l.l [Software]: Program¬ 
ming Techniques—Applicative (Functional) Programming 

General Terms Design, Theory 

Keywords Functional Reactive Programming, Concurrency, Live- 


1. Introduction 

Many classes of programs are reactive: they run for a long period of 
time during which they interact with their environment. Examples 
of reactive programs include control systems, servers, and any 
program with a graphical user interface. 

Many reactive programs are implemented using an event-driven 
model, in which stateful components send and receive events which 
update their state, and may cause side-effects such as network 
traffic or screen updates. The event-driven model forms the basis 
of Actors fl2i . and the Model View Controller architecture of 
Smalltalk (5). 

The event-driven model has a number of challenging features, 
including: 
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• Concurrency: reactive programs often have concurrent features 
such as dealing with multiple simultaneous events. This either 
leads to multithreaded languages such as Java, with complex 
concurrency models 0 Ch. 17], or single-threaded languages 
such as ECMAScript which do not naturally support multicore 
execution, and rely on cooperative multitasking. 

• Imperative programming: components are stateful, and may re¬ 
spond to events by updating their internal state. These hidden 
side-effects can result in complex implicit component interde¬ 
pendencies. 

• Referential opacity: since components support mutable state, 
component identity is important. The semantics for components 
is not referentially transparent, since creating a component and 
copying it is not equivalent to creating multiple components. 

• Callbacks: the idiom for programming in an event-driven model 
is registering callbacks rather than blocking function calls. For 
example, in ECMAScript an HTTP request is not a blocking 
method call, but instead a non-blocking call which registers a 
callback to handle the result of the HTTP request. This essen¬ 
tially requires the programmer to convert their program to Con¬ 
tinuation Passing Style (CPS) 122). Manual CPS transformation 
can be error-prone, for example, calling the wrong continua¬ 
tion, or mistakenly calling a continuation twice. In the absence 
of call/cc, CPS transformation is a whole-program translation, 
so can require a large codebase to be rewritten. 

Functional Reactive Programming allows reactive programs to be 
written in a pure functional style. Originally developed by El¬ 
liot and Hudak El as part of the Fran functional animation sys¬ 
tem, there are now a number of implementations, including Agda 
FRP (B), Flapjax (20], Frappe (8). Froc 0, FrTime Q, Grape¬ 
fruit (161 , Reactive fTol . Reactive-Banana 0, and Yampa (231. 
Comparing FRP with the event-driven model, we have: 

• Pure junctional model: there are no implicit interactions caused 
by shared mutable state, and a simple concurrency model. 

• Referentially transparent: signals can be copied without alter¬ 
ing their semantics. 

• Direct: FRP programs are given in direct style rather than CPS. 

Comparing FRP with synchronous dataflow languages such as Es- 
terel (3), some key distinctions are: 

• Fine-grained time: FRP often models time as a continuous 
domain (such as R) or using a much finer unit of time than the 
sample frequency of a synchronous language (such as 1ms). 

• Higher-order signals: FRP allows signals of signals, which 
model dynamically reconfigurable dataflow networks. 
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• Embedded DSL\ FRP is typically implemented as an embedded 
DSL library in a functional host language (often Haskell, but 
also Agda [13), ECMAScript (20), Java QD, OCaml [9), or 
Scheme (7)). 

In this paper, we consider the problem of liveness of an FRP 
program. 

• We develop a type system and model of FRP which provides 
liveness guarantees. 

• We show how to define guarded fixed points, and provide live¬ 
ness in the presence of recursion. 

• We give an implementation of FRP in terms of programming 
over sets and relations, which are in turn implemented using 
callbacks. 

• We discuss a multithreaded Java implementation of the model. 

This is the first work to provide liveness guarantees for event-based 
programs in FRP. Moreover, in implementing FRP in terms of a 
model of sets and relations: 

• The isomorphism between event sources and behaviours cor¬ 
responds to the isomorphism between relations and set-valued 
functions. 

• The implementation of sets and relations using the usual 
double-negation CPS transform allows the implementation 
of behaviours as pull systems based on futures, and of event 
sources as push systems based on the observer pattern, to arise 
from first principles. 

• The implementation of event sources as relations allows natu¬ 
rally for concurrent execution, and in particular for out-of-order 
arrival of events. Most combinators naturally allow for concur¬ 
rency, and it is only combinators which rely on ordering (such 
as an accumulation function) which force an order on events. 

This is the first such investigation of the relationship between 
FRP and a CPS implementation of sets and relations, and the first 
implementation of concurrent FRP using out-of-order events. 

2. History-free programs 

In this section, we present our core FRP model, with types, combi¬ 
nators, and their semantics. For readability, we present the model in 
pseudo-Haskell: the actual implementation is in Java, as discussed 
in Section [6] We start by presenting the combinators for history- 
free programs: history-sensitive programs are discussed in the next 
section. 

The semantics of FRP is defined in terms of behaviours over a 
total order Time, whose semantics are given as total functions from 
time to values: 


[[Behaviour A] = Time -4 [A] 
and event sources which are partial functions: 

[[Event A] = Time->• [A]_l 


Signal types come with a collection of combinators such as: 
map : (A-t B)-} Event A —*■ Event B 
filter : (A—> Boolean) -> Event A —»• Event A 


whose semantics are as 
[map] f at = 


e might expect: 

lift (/*) if at = lift a; 
.L otherwise 


[filter] fat 


lift a; if a t = lift x and / x 
J_ otherwise 


For example, a simple web server, which responds “Hello, World!” 
to any GET request might be written: 


server : Event HTTPRequest —» Event HTTPResponse 
server reqs = getResps where 

getReqs = filter isGetRequest reqs 

getResps = map hello getReqs 

hello req = httpResponse200 "Hello, World! " 


assuming a library for HTTP messages: 

isGetRequest : HTTPRequest—>■ Boolean 
httpResponse : Integer —>• String —» HTTPResponse 
Unfortunately, this server has a serious problem: it suffers from a 
lack of liveness, in that a non-GET request will result in no response 
at all. To fix this, we introduce explicit error handling: 


server : Event HTTPRequest —>• Event HTTPResponse 
server reqs = union getResps otherResps where 

(getReqs, otherReqs) = partition isGetRequest reqs 

getResps = map hello getReqs 

otherResps = map error otherReqs 

hello req = httpResponse 200 "Hello, World!" 

error req = httpResponse 405 "Method not supported." 


This uses combinators for partitioning and recombining events: 
partition : (A —» Boolean) —» Event A —> (Event A x Event A) 
union : Event A —> Event A —> Event A 


The semantics of partitioning is simple: 

[partition] fo = ([filter] / a, [filter] (-. o /) a) 

The semantics of recombining is not so simple, since we have to 
account for the possibility that events will arrive simultaneously 
from both sources. The easiest thing to do is to prioritize one source 
over the other, for example to prioritize the first source: 


[union] 


lift a? if at = lifts 
t t otherwise 


Unfortunately, this approach is problematic for three reasons: 


This semantics for union xsys is not commutative, even though 
in its idiomatic usage xs and ys have disjoint domains. 


X± — {J.} U {lift* | x € X} 

We will sometimes refer to signals when we want to talk about both 
behaviours and events. 

The timestamps for events are based on the time an event first 
enters the FRP system, not the current wall-clock time. For exam¬ 
ple, a function on event sources which processes a event x with 
timestamp t to an event / (x) will still emit f(x) with timestamp t, 
irrespective of the running time of /. 


• The types for partition and union permit the original buggy 
server, so do not provide liveness guarantees. 

• The implementation of union xsys is difficult, in that an event 
from ys at time t cannot be emitted until we know that xs will 
not generate an event at time t. This may cause events from ys to 
be unnecessarily buffered, and requires the presence of negative 
information (xs will not generate an event at time t). 

For these reasons, we propose an alternative type system for be¬ 
haviours and events. Rather than event sources being partial func- 
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[EventT A] = [T] 4 [A] 

[Behaviour T A] = [T] 4 [A] 

[MinusTS] = [T] \ [S] 

event : Behaviour T A —> Event T A 

[event] a = a 

buffer: Event T A 4 Behaviour T A 
[buffer] a = a 

map : (A-y B)—> Event TA —» Event TB 
[map] f at = f (at) 

map : (A 4 B) 4 Behaviour T A —y BehaviourT B 
[map] f crt = f (at) 

map2 : (A 4 B 4 (7) —» Behaviour T A 4 BehaviourTB 4 Behaviour TC 
[map2] / art = / (erf) (rt) 

map2 : (A 4 B 4 C) —* Event T A 4 Behaviour TB —> Event TC 
[map2]/art = /(af)(rt) 

partition : (A 4 Boolean) —y Event T A —>• 3(5 < T)(EventSA x Event (MinusT S) A) 
[partition] / a = (X , r, p) where X — {t | / (at)} and rt = crt and pt = crt 
union : EventSA-* Event (Minus TS) A —» EventTA 
[union] a r = a U r 

Figure 1. History-free fragment, where [S] C [T] C Time is locally finite and well-ordered 


tions with domain Time, we propose viewing them as total func¬ 
tions whose domain is a subset of Time, that is: 

[EventTA] = [T] -4 [A] 

Since event sources are total, they guarantee liveness in the sense 
that they will produce a value for any time in [T]. For symmetry, 
we parameterize behaviours hy the times at which they change: 

[Behaviour T A] = [T] -4- [A] 

To ensure the existence of fixed points, as discussed in Section [3] 
we require that [T] C Time is locally finite (that is every interval 
[s, t] from [T] is finite) and well-ordered (every non-empty subset 
of T has a least element). Note that T is being used as a phantom 
type fl9l : it is a fiction of the types for signals, and its implementa¬ 
tion is not necessarily as a subset of Time. 

Semantically, events and behaviours are equivalent, and indeed 
they form an isomorphism given by: 

event : Behaviour T A 4- EventTA 
buffer : EventTA—>■ BehaviourTA 
As we shall see, their implementations are quite different (be¬ 
haviours are implemented as pull systems, and events are imple¬ 
mented as push systems). In particular, the event function intro¬ 
duces no overhead, but the buffer function introduces buffering, 
and so may have a significant memory overhead. 

We are careful about when we use Behaviour types and when 
we use Event types to ensure that the only source of buffering from 
the primitives is the buffer function. For example, we provide two 
functions for mapping a binary function over two signals: 
map2 : (A 4 .B 4 C) 4 

Behaviour T A 4 Behaviour T B 4- Behaviour T C 
map2 : (A 4 B 4 C) 4 

Event T A 4 Behaviour T B 4 Event TC 


In both cases, one of the signals must be a behaviour, and if we wish 
to combine two event sources, we must first buffer one of them, for 
example if xs, ys : Event T Integer then: 

map2 (• + -)xs (bufferys) : Event T Integer 
We do not provide a combinator: 

map2 : (A 4 B 4 C) 4 

Event T A 4 Event T A 4 Event T A 

since map2/xsys cannot be implemented without buffering: an 
event with timestamp t may arrive from xs at wall-clock time ti, 
with the matching event from ys arriving at wall-clock time fo; 
events must be buffered to allow for the differences in wall-clock 

The type for map is unchanged, and its semantics is simplified, 
since events are now total: 

map : (A 4 B) 4 Event T A 4 Event T B 
[map] f crt = f {crt) 

The type for filter must change: if xs has domain T, then filterf xs 
will not have domain T, hut will instead have some subdomain 
of T. To model this, we use bounded existential types (6), with 
semantics: 

[3(A < B){F A)] = {(X, [F]X) | X C [B]} 

The type and semantics of filter are then: 
filter : (A 4 Boolean) 4 Event T A 4 3{S < T) (Event S'A) 
[filter] fa — (X, r) where 
X = {t | / (at)} and rt = crt 
For example, if: 

[things] ={0 4 apple, 1 4 cat, 2 4 banana} 
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then: 

[filter isFruit things] = ({0, 2}, {0 i—apple, 2 i->- banana}) 
For partitioning, we could just continue to treat a partition as a pair 
of filters, which would give the type: 

partition : (A —> Boolean) —» Event T A —t 

(3 (S < T)(Event S A) x 3 (R < T)(EventRA)) 
However, with this type, we have lost the information that T has 
been partitioned into S and R. Instead, we provide a more refined 
type, in which we set R to be MinusT S: 

partition : (A —»• Boolean) —> Event T A —»• 

3(5 <T) (Event S Ax Event (MinusT S) A) 
where MinusT S is interpreted as set subtraction (maintaining an 
invariant that [5] C [T]): 

[MinusT5] = [T] \ [5] 

The semantics of partition is: 

[partition] f a = ( X , r, p) where 
X = {t | f (at)} and rt = at and pt = at 
For example: 

[partition isFruit things] = 

({0,2}, {0 1-4 apple, 2 banana}, (1 i->- cat}) 

The benefit of this refined type for partition is that it allows for a 
better treatment of union: 

union : Event S A —>■ Event (MinusT S) A —»• Event T A 
[union] err = a Ur 
For example, if we define: 

mkDogxs = union fruit dogs where 
(fruit, rest) = partition isFruitxs 
dogs = map (Aa:. dog) rest 

then we have: 

[mkDog things] = (0 i—>■ apple, 1 i->- dog, 2 i-» banana} 

This addresses the three issues we highlighted earlier: 

• The semantics of union is commutative. 

• The fixed version of the HTTP server typechecks with type 
server : Event T FITTPRequest —> Event T FITTPResponse. 
The buggy server does not typecheck with this type. In general, 
the semantics of Event T A require liveness for all of T. 

• The implementation of union xsys is simple: when an event 
from either xs or ys is generated, it can immediately be emitted. 
No negative information is required. 

In Figure[l]we summarize the history-free fragment of our model. 

3. History-sensitive programs 

So far the FRP combinators only allow history-free programs to 
be defined, in that output behaviour at time t can only depend on 
input behaviour at time f, not at any time before t. We now present 
combinators which support history-sensitive programming. 

The simplest form of history-sensitivity is the delay function, 
which takes a behaviour, and delays it by one unit of time: 
delay : Behaviour T A—> Event (Tail T) A 
[delay] ofi+i =ati 
For example: 

[delay things] = (1 i-t apple, 2 1-4 cat} 


Here we are making use of the requirement that T is a locally finite 
and well-ordered, since this means that: 

[T] = (to < 1 1 < t 2 < ■ ■ ■ } 

In particular we can then define the tail of T to be every element 
other than the least one: 

[Tail T] = if [T] = 0 then 0 else [T] \ {t 0 } 

We can similarly define the tail of a behaviour to be every element 
but the first: 

tail : BehaviourTA —» Behaviour (Tail T) A 
[tail] at = at 
For example: 

[tail things] ={li-t cat, 2 i-t banana} 

We cannot, however, provide a matching head function with type 
Behaviour T A —} A, since to may be in the future (and indeed T 
may be empty, so no such A may exist). Instead, we allow a peek 
function, which allows the first element to be inspected as long as 
an event is being produced: 

peek : Behaviour T A —► {A —► Event T B) —>• Event T B 
[peek] a f = f (ato) 

For example: 

[peek things (Ax . if isFruit x then ys else zs)] = [ys] 

These functions allow signals to be decomposed, we can also com¬ 
pose them, for example: 

cons : A —¥ Event (Tail T) A —>■ Event T A 
x if t = to 
a t otherwise 

for example: 

[cons dog (event (tail things))] 

= {0 1—>- dog, 1 i->- cat, 2 i->- banana} 

Finally, we consider recursively defined behaviours. We will only 
allow the solution to guarded equations, in the sense that behaviour 
at time U+i can only depend on recursive behaviour up to time 
U. We ensure this by introducing an explicit delay, that is we are 
solving: 

a = f ([delay] a) 

Since all definable functions on signals are causal (output at time t 
only depends on input up to time t ) we have that <r’s value at time 
ti+i only depends oaf ([delay] a) ’s value at time U+i, which only 
depends on ([delay] a) ’s value up to time fi+i, which only depends 
on cr’s value up to time U. Thus, a is well-defined. For a more 
formal treatment of the well-definedness of guarded equations, see 
Krishnaswami and Benton’s ultrametric space semantics fl8l . or 
the author’s use of parametricity to ensure causality fl4l . 
Unfortunately, the obvious type for fixed points: 
fix : (Event (Tail T) A —> BehaviourTA) — y BehaviourTA 
has a problem. We are maintaining an invariant that all time do¬ 
mains are locally finite and well-ordered, but if we were to allow fix 
to exist for all T, then we could use it to inhabit Behaviour R + A, 
for example: 

fix(Axs. buffer(cons(0,xs))) 

Since R + is locally infinite and non-well-ordered, this would be 
problematic. To avoid this, we introduce a type of clocks, which is 
only inhabited when T C Time is locally finite and well-ordered, 
in which case its semantics is trivial: 

[Clock T] = {*} 
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[[Tail T] = if [TJ = 0 then 0 else [[T] \ {f 0 } 

[Clock T] = {*} 

peek : Behaviour T A —>• (A —>■ Event TB) -4 Event TB 
[peek] a f = f (cr to) 

tail : Behaviour T A -4 Behaviour (Tail T) A 
[tail] art = at 

delay : Behaviour T A —» Event (Tail T) A 
[delay] at i+ 1 = ati 

cons : A —> Event (Tail T)A—t Event T A 

clock : Behaviour T A -4 Clock T 
[clock] a = * 

fix : Clock T -4 (Event (Tail T) A -4 Behaviour T A) -4 Behaviour T A 
[fix] cf = a where a = f ([delay] a) 

Figure 2. History-sensitive fragment of our FRP model, where [T] = {to < fi < t 2 < ■ ■ ■ } 


The modified type for fix uses a clock element to ensure that it is 
safe to inhabit Behaviour T A: 

fix : ClockT—t (Event (TailT) A—>■ BehaviourT A) -4 BehaviourTA 
[fix] cf = a where a = / ([delay] a) 

For example, we can use fix to define a constant behaviour: 
constant: Clock T -4 A -4 Behaviour T A 
constantcx = fixe (Axs . buffer(cons(x,xs))) 

[constant] ext = x 

We can also use fix to define an accumulator function: 
accum : (B -4 A -4 B) -4 B -4 Behaviour T A —>■ Behaviour TB 
accumfyxs = fix(clockxs) (Ays . buffer(map2f cons(y,ys)xs)) 
making use of a function to extract a clock from a behaviour: 
clock : Behaviour T A —¥ Clock T 
[clock] a-* 

For example if: 

a = {to i-F xa,t\ i-t xi,t2 X2, ■ ■ ■} 

[accum] |* + -)0ff = 

{t 0 i-4 x 0 ,ti h4 (x 0 + an),*2 i-t (so + xi + x 2 ), ■ ■.} 

In Figure [2] we summarize the history-sensitive fragment of our 
FRP modek 

4. Implementation of behaviours and events 

The implementation of signals is built on top of a library of sets 
and relations. In Figure [3] we give the model of sets and relations, 
we defer discussing its implementation until the next section. It 
provides two types, for sets and relations: 

[Set A\=V [A] 

Relation AB = Set (A x B) 

together with a collection of combinators for these types. Of par¬ 
ticular interest is the isomorphism between relations (V (X x Y)) 


[Set A]= 7 >[A] 

Relation AB = Set (A x B) 
buffer: Relation AB -4 A —» Set B 
[buffer] R x = {y \ (x, y) £ R} 
empty : Set A 
[empty] = 0 
singleton : A -4 Set A 
[singleton] x = {a;} 
union : Set A —> Set A —>• Set A 
[union] X Y = X UY 
pmap : (A -4 Set B) -4 Set A -4 Set B 
[pmap] f X = {y \ x £ X,y £ f x} 
fix: ((A —» Set .B) —» (A —^ Set S)) —^ A —^ Set B 
[fix] / = the smallest g such that \/x . f gx C gx 

Figure 3. Model of sets and relations 

and set-valued functions (X —>VY) given by the functions: 
relation : Set A — > (A —► Set B ) -4 Relation A B 
relationxsf = pmap (Ax . map (x, •) (f x)) xs 
[relation] X f = {(x,y) \ x e X,y e f x} 
buffer: Relation AB4A4 Set B 
[buffer] R x m {y \ (x, y) £ R} 

Given a relation R whose domain (that is {x\3y . (x, y) € Rj) is 
X, we have: 

[relation] X ([buffer] R) = R 

and given a function / whose domain (that is {x \ 3y . y € / a:}) 
[buffer] ([relation] X f) = f 


2013/5/22 




We shall see later that this isomorphism generates the isomorphism 
between behaviours and event sources. 

The combinators include a fixed point function: 

fix: ((A —» Set .B) —>■ (A —>■ Set B)) —>■ A —>■ Set B 
[fix] / = the smallest g such that Vk . / g x C g x 

This function is well-defined because the only implementable func¬ 
tions are monotone with respect to C. 

Using the combinators given in Figure [3] we can derive other 
combinators such as: 

map : (A —>• B) —>■ Set A —} Set B 
mapf = pmap (Ax . singleton(f x)) 

[map] fX = {fx\xG X} 

pmapr : (B —>• Set C) —> Relation AB —»• Relation A C 
pmaprf = pmap (A(x, y) . map (a;, •) (f y)) 

[pmapr] f R= {(®, z) \{x,y)£R,z€f y} 

filter : (A —>• Boolean) —► Set A —>• Set A 

filter f = pmap (Ax . if f x then singleton x else empty) 

[filter] fX — {x\xeX,fx} 

domain : Relation AB -3 Set A 

domain = map (A(x, _) . x) 

[domain] R = {x\3y . (x,y) € R} 

In particular, we can implement the categorical structure of rela¬ 
tions, with identity and composition: 

diagonal : Set A —»• Relation A A 
diagonal = map (Ax . (x, x)) 

[diagonal] X = {(a:, x) \ x € X} 

comp : Relation AB —» Relation BC-> Relation AC 

comp q r = pmapr (buffer r) q 

[comp] QR={(x,z) | (*, y) € Q, (y, z) 6 R} 

We shall now consider an implementation of FRP using sets and 
relations, beginning with the implementation of clocks. A clock is 
implemented as an abstract datatype whose implementation is: 

data Clock T = Clock { 
times : Set Time, 
first : Set Time, 
prev : Relation Time Time, 
parent : T 

} 

We maintain the following invariants about c : Clock T, where 
[T] C Time is locally finite and well-ordered, and so [T] is of the 
form (to < ti < ta < • • • }: 

• [times c] = [T]. 

• [first c] = {to} (or 0 when [T] = 0). 

• [prev c] = | U+i > to}- 

Note that every element of Clock T is equal (and in fact we use 
memoization to ensure that every T has at most one Clock T). 
Clocks are needed as a way to access at run time the total order 


on T. We can implement a function: 
tail : ClockT-t Clock (Tail T) 
tailc = Clock} 

times = domain (prevc) 

first = pmap (At. domain(filter (A(_, u) . t = u) (prev c))) (first c) 
prev = pmap (At. filter (A(_, u) . t < u) (prev c)) (first c) 

} P 

The reason for having a parent element is to implement: 

tail" 1 : Clock (Tail T)-4 Clock T 
The concrete implementation of Tail T is: 

data Tail T = Tail {clock : Clock T} 
so we can define: 

tail -1 c = clock (parent c) 

The implementation of Minus T and minus -1 are similar. We can 
now turn our attention from clocks to behaviours and event sources. 

The concrete implementation of a behaviour is a clock together 
with a function from time to sets of events: 

data Behaviour T A = Behaviour} 
clock : Clock T, 
function : Time —» Set A 

} 

and the concrete implementation of an event source is a clock 
together with a relation between time and events: 

data Event T A = Event { 
clock : Clock T, 
relation : Relation Time A 

} 

As we shall see when we look at the implementation of sets and 
relations, behaviours are implemented as pull systems, and event 
sources are implemented as push systems. We maintain the follow¬ 
ing invariants about xs : BehaviourT A and ys : Event T A: 

• For any t € [T], the set [function xs] t is a singleton. 

• The domain of [relation ys] is [T], 

• For any (t, x) € [relation ys] E5 (t, y), we have x = y. 

These invariants mean that it is straightforward to translate the 
concrete semantics of signal to their abstract semantics: 

[xs] t = the unique x such that x € [function xs] t 
[ys] t = the unique x such that (t, x) € [relation ys] 

We can then implement the FRP combinators, and verify that they 
maintain the invariants and have the expected semantics. Most are 
quite straightforward given the model of sets and relations, for 
example the isomorphism between behaviours and events is just 
given by lifting the isomorphism between functions to sets and 
relations: 

event : BehaviourT A —» Event T A 
event (Behaviourcf) = Eventc (relation (timesc) f) 
buffer : Event T A -»• BehaviourT A 
buffer (Event cr) = Behaviour c (buffer r) 
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[Not A] = [A] -»■ 2 

buffer : Not (Not (A x B)) -+ A -+ Not (Not B) 

[buffer] kxt = k (A (a :',y) . (x = x') A £{y)) 
discard : Not A 
[discard] x = false 
doubleNot : A —> Not (Not A) 

[doubleNot] xk = kx 

andthen : Not A—>• Not A—* * Not A 

[andthen] klx = kx V Ex 

copmap : (B -¥ Not (Not A)) —t Not A —> Not-B 

[copmap] fky = fyk 

fix: ((A—> Not-B) —t (A—t Not-B)) —t A—» NotB 
[fix] / = the smallest g such that \/x ,\/y . f gxy ^ gxy 

Figure 4. Model of continuations 

The delay function is implemented by mapping the behaviour over 
the previous time relation: 

delay : Behaviour T A —> Event (Tail T) A 

delay (Behaviour cf) = Event (tailc) (pmaprf (prevc)) 

The cons function is just the union of the head and the tail: 
cons : A —» Event (Tail T) A —t Event T A 
cons x (Event c r) = Event c'(union r r') where 
c' = tail -1 c 

r- *sc map (first c') (At. (t,x)) 

The union function is just union of relations: 
union : Event S A—> Event (Minus T S) A —»• Event T A 
union (Event _q) (Event c r) = Event (minus -1 c) (union q r) 

We defer a discussion of the implementation of partition to Sec- 
tion[6] The implementation and verification of the remaining prim¬ 
itives is straightforward. 

5. Implementation of sets and relations 

The implementation of signals is built on top of a library of contin¬ 
uations. In Figure|4]we give the model of continuations, we defer 
discussing its implementation until the next section. It provides a 
type of continuations: 

[Not A] = [A] —► 2 

together with a collection of combinators for these types. These 
combinators correspond directly to the combinators for sets, since 

data Set A = Set {unSet : Not (Not A))} 
and then define: 

buffer (Set xs) = Set ■ (buffer xs) 

empty = Set discard 

singleton x = Set (doubleNot x) 

union (Setxs) (Setys) = Set (andthen xsys) 

pmapf (Setxs) = Set (comap (copmap (unSet • f))) 

fixf = Set • fix (Ag . unSet ■ f (Set • g)) 


public class Events<T,A> { 

public final Clock<T> clock; 

public final Relation<Time,A> relation; 

public<B> Events<T,B> 

map(Function<A,B> f) { ... } 
public Behaviour<T,A> 
buffer!) {...}■ 
public PartitionedEvents<?,T,A> 
partition(Predicate<A> p) { ... } 


public interface PartitionedEvents<S extends T,T,A> { 

public Events<S,A> yes(); 
public Events<Minus<T,S>,A> no(); 
public<Z> Z 

split(Function2< 

Events<S,A>, 

Events<Minus<T,S>,A>, 

Z> f); 


Figure 5. Event sources in Java 


where: 

comap : (B — }■ A) —} Not A —> Not B 
comap f = copmap (Ay . doubleNot (f y)) 

We can translate from the concrete semantics of sets to their ab¬ 
stract semantics as: 

[xs] = {x I [unSetxs] (Ax'. x = x')} 

It is straightforward to verify that the combinators on sets have their 
expected semantics. 

We have now shown that a model of FRP can be translated 
into a model of sets and relations, and from there to continuations. 
Composing these translations, we get: 

BehaviourT A C ClockT x (Time Not (Not A)) 
EventTA C ClockT x Not (Not (Time x A)) 
that is: 

• Behaviours are implemented as pull systems: a user of a be¬ 
haviour can call it with a time t € [T], and receive back a future 
value, of type Not (Not A). A client can then register callbacks 
of type Not A with the future, which will be executed when the 
value is known. Since we maintain an invariant that behaviours 
return singletons, each callback will be executed precisely once. 

• Events are implemented as push systems: a user of an event can 
register a callback of type Not(Time x A) with it, which will be 
executed with pairs (t, x) whenever an event x arrives at time t. 
We maintain an invariant that each time t has a unique x, and 
that all times t € [T] will generate an event. 

It is interesting that the implementation of reactive programs as 
push or pull systems, and the uses of futures and the observer pat¬ 
tern fall out naturally from the translation of signals to sets and re¬ 
lations, and then to continuations. Moreover, the isomorphism be¬ 
tween push systems and pull systems is given by the isomorphism 
between relations and set-valued functions. 
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public<T> Events<T,HttpResponse> 

responses(Events<T,HttpRequest> requests) 

{ 

return requests.partition(request -> 
request.isGetRequest() 

).split((getReqs,otherReqs) -> 
getReqs.map(request -> 

new HttpResponse(200,"Hello, World!") 
).union(otherReqs.map(request -> 
new HttpResponse(405) 

)) 

); 

> 


Figure 6. Example “Hello, World!” server implemented in Java 

public interface Not<A> { 
public void accept(A x); 

default public<B> Not<B> comap(Function<B,A> f) { 
return y -> { this.accept(f.apply(y)); >; 

> 

default public Not<A> andthen(Not<A> other) ■[ 

return x -> { this.accept(x); other.accept(x); }; 

> 


} 


public interface Not2<A,B> { 
public void accept(A x. By); 


} 


Figure 7. Continuation classes in Java 


6. Java implementation 

The FRP implementation is in Java, and is a direct translation 
of the model discussed in Sections |2jj5] Part of the interface for 
event sources is given in Figure[5] and is the Java equivalent of the 
relevant fragment of Figure[l] We make use of Java 8’s support for 
anonymous functions (where \x . M is written in Java as x -> M). 

There is a slight difference in the way Java treats bounded 
existential types, which is by wildcarding (the ? type in the return 
type of partition). Java does not support direct unpacking of 
existential types, and instead unpacking must be performed by 
helper functions. For example in Java one cannot write: 

Events<T,Integer> xs = ...; 

PartitionedEvents<S,T,Integer> p = 
xs.partition(x -> 0 <= x); 

Events<S,Integer> pos = p.yesO; 

Events<Minus<T,S>,Integer> neg = p.no(); 

return pos,union(neg.map(Math.abs)); 
because there is no way to introduce the new bound type variable 
S. Instead, one writes: 

Events<T,Integer> xs = ...; 


public class NotImpl<A> implements Not<A> { 

protected List<Not<A» conts; 

final WeakReference<NotNotImpl<A» not; 

public NotImpl(NotNotImpl<A> not) { 
this.not = new WeakReferenceo(not) ; 

} 

public void accept(A x) { 

List<Not<A» ks; 

NotNotImpl<A> not; 
synchronized(this) { 
ks = this.conts; 
not = this.not.get(); 
if (not != null) ■[ 

not.values = new Listo (x, not .values); 

> 

> 

while (ks != null) {. 

ks.hd.accept(x); ks = ks.tl; 

> 

> 


public class NotNotImpl<A> implements Not<Not<A» { 
protected List<A> values; 

final NotImpl<A> not = new Notlmplo(this) ; 

public void accept(Not<A> k) { 

List<A> xs; 

synchronized(this.not) { 
xs = this.values; 

this. not. conts = new ListO(k,this .not. conts) ; 

> 

while (xs != null) { 

k.accept(xs.hd); xs = xs.tl; 

> 

} 


Figure 8. Mutable implementation of continuations 


return xs.partition(x -> 

0 <= x 

).split((pos,neg) -> 

pos.union(neg.map(Math.abs)) 

) 

Inside the anonymous helper function, an anonymous type variable 
S is created, pos is given type Events<S,Integer> and neg is 
given type Events<Minus<T, S>, Integer>. 

The example “Hello, World!” web application is shown in Fig¬ 
ure [6] An implementation of an asynchronous servlet allows it to 
execute in any servlet container, resulting in the interactions: 

$ curl -i localhost:8080/hello 
HTTP/1.1 200 OK 
Cont ent-Length: 13 
Server: Jetty(9.0.0.M5) 

Hello, World! 


2013/5/22 





public class FunctionNotNotRef<A,B> 
implements Function<A,Not<Not<B»>, 
Not<Function<A, Not<Not<B»» 

{ 

protected Function<A,Not<Not<B»> delegate; 
protected HashMap<A, NotNot Impl<B» cache = 
new HashMap<>(); 

public Not<Not<B» apply (A x) { 
Function<A,Not<Not<B»> f; 

NotNotImpl<B> k = null; 
synchronized (this) { 
f = this.delegate; 
if (f == null) { 

k = this.cache.get(x); 
if (k == null) -( 

k = new NotNotImpl<B>(); 
this.cache.put(x,k); 

} 

> 

if (f == null) { 
return k; 

return f.apply(x); 

> 

> 

public void accept (Function<A,Not<Not<B»> f) { 
HashMap<A,NotNotImpl<B» cache; 
synchronized (this) { 
cache = this.cache; 
this.cache = null; 
this.delegate = f; 

> 

f or ( 

Entry<A, NotNot Impl<B» e : cache . entrySet () 

) { 

A x = e.getKeyO ; 

Wot<B> k = e.getValueO .not; 
f.apply(x).accept(k); 

} 

> 


public<A,B> Function<A,Not<Not<B»> fix( 
Function< 

Function<A, Not<Not<B»>, 
Function<A,Not<Not<B»> 



FunctionNotNotRef<A,B> g = 
new FunctionNotNotRef<A,B>(); 
Function<A,Not<Not<B»> h = 
f.appiy(g); 
g.accept(h); 
return h; 


Figure 9. Implementation of fix 


public class FunctionNotNotImpl<A,B> 

implements Function<A,Not<Not<B»>, Not2<A,B> 

{ 

final WeakHashMap<A,NotNotImpl<B» cache = 
new WeakHashMap<>(); 

public synchronized NotNotImpl<B> apply(A x) { 
NotNotImpl<B> k = this.cache.get(x); 
if (k == null) { 

k = new NotNotImpl<B>(); 
this.cache.put(x,k); 

> 

return k; 

} 

public void accept (A x. By) -[ 
this.apply(x).not.accept(y); 

> 

} 

public<A,B> Function<A,Not<Not<B»> 
buffer (Not<Not2<A ,B» k) 

{ 

FunctionNotNotImpl<A,B> f = 
new FunctionNotNotImpl<A,B>(); 
k.accept(f); 
return f; 

} 


Figure 10. Implementation of buffer 


and: 

curl -i -d "Stuff" localhost:8080/hello 
HTTP/1.1 405 Method Not Allowed 
Cont ent-Length: 0 
Server: Jetty(9.0.0.M5) 

Most of the work in the FRP implementation is in implement¬ 
ing the continuation classes Not<A> which represents Not A and 
Not2<A,B> which represents Not (A x B). The implementa¬ 
tion of Not<A> is as an interface with a single abstract method 
void accept (A x). This method is allowed to be side-effecting 
(although care is required from any programmer working at this 
low level to respect the high-level semantics). Figure[7]shows some 
of the implementation of the classes. 

One implementation of continuations is a pair of mutable con¬ 
tainers, given in Figure [8] One is a container of Not A continua¬ 
tions, and implements Not A; the other is a container of A values, 
and implements Not (Not A). When a new continuation is added 
(by calling accept on the value container), it is applied to all of 
the existing values. Similarly when a new value is added (by call¬ 
ing accept on the continuation container), all the existing contin¬ 
uations are applied to it. Note that there is only a weak reference 
from the continuation container to the value container, so the value 
container can be garbage collected without impacting the continu¬ 
ation container. 

To ensure thread-safety of the implementation, appropriate 
locking is used on critical sections. Note that we never call any 
callbacks while holding a lock, so there is never any attempt to 
acquire two locks simultaneously. Thus, the code is deadlock-free, 
and will not introduce issues with liveness. 
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public class ClockImpl<T> extends Clock<T> { 

final Not<Time> ntimes; 
final Not<Time> nfirst; 
final Not2<Time,Time> nprev; 


public class EventsImpKT,A> extends Events<T,A> C 

final public ClockImpl<T> clock; 
final public Not2<Time,A> nrelation; 


public class PartitionedEventsImpKT,A> 
implements PartitionedEvents<T,T,A> 

{ 

final Predicate<A> pred; 

final EventsImpKT,A> yes; 

final EventsImpl<Minus<T,T>,A> no; 

final WeakHashMap<Time,Boolean> flags; 
final HashMap<Time,Time> prevUnknown; 
final HashMap<Time,Time> nextUnknown; 
final HashMap<Time,Time> prevSame; 
final HashMap<Time,Time> nextSame; 

Time first = null; 

public PartitionedEventsImpK 

Predicate<A> pred, Events<T,A> xs 

) { 

this.pred = pred; 

this.yes = new Eventslmpl<>(...); 

this.no = new Eventslmpl<>(...); 

xs.relation.pairs.accept(this::acceptEvent); 

} 

public void emitTime(Time t. Boolean flag) { 
if (flag) { this.yes.clock.ntimes.accept(t); } 
else { this.no.clock.ntimes.accept(t); > 

> 

public void emitEvent(Time t, Ax, Boolean flag) { 
if (flag) { this.yes.nrelation.accept(t,x); > 
else { this.no.nrelation.accept(t.x); } 

> 

public void acceptEvent(Time t. Ax) { 

Boolean tflag = this.pred.apply(x); 

synchronized (this) { this.flags.put(t,tflag); } 
this.emitEvent(t,x,tflag); 
this.emitTime(t,tflag); 

> 


Figure 11. Implementation of partition 


The two methods of Not A which require effort are fix (which 
finds the fixed point of set-valued functions) and buffer (which 
implements half of the isomorphism between relations and set¬ 
valued functions). These two functions are implemented similarly, 
in that under the hood they are based on mutable continuations, and 
use a HashMap to buffer values. The implementations are given in 
Figures[9|and[lQ| 

In the case of fix, we make use of a class FunctionNotNotRef 
which implements A —>• Not (Not B) by acting as a delegate to 
another function of the same type. Crucially, the delegate may 
be set after the reference has been created, so the function has 
to respond to apply in the absence of its delegate. It does so by 
creating a new mutable Not (Not A), which it stores in a cache 
before returning. When the delegate is set, it runs through the 
cache, initializing all of the cached continuations appropriately. 
Thus, a suitable mix of buffering and mutable state allows cyclic 
structures to be built which give the appearance of pure functional 
fixed points. 

The implementation of buffer is similar, but there is one crucial 
difference. In the case of fix, the buffering is only required after the 
reference has been created, but its delegate is initialized. In most 
cases, this will be transitory, and the buffer will not be long-lived. 
In the case of buffer, the buffer will be long-lived, and we need to 
take care that it does not cause a space leak. For this reason, we use 
a weak hash map to store the buffer. When a key in the buffer can 
be garbage collected, it will be, and the corresponding value will 
be removed. 

In its use in the FRP implementation, FunctionNotWotlmpl is 
always used to implement a function of type Time —> Not (Not A), 
and so every use of buffering will introduce a WeakHashMap whose 
keys are Time. This makes Time objects quite expensive: even 
though each Time object is small (just containing a long times¬ 
tamp) each live Time object is also keeping alive many entries in a 
buffer. For this reason, the FRP interface does not expose Time ob¬ 
jects to user code, since it would be very easy to introduce a space 
leak by holding on to a time object. In our setting, this is the form 
that time leaks take j2Tj, even though Java is a strict language. 

There is one method of signals which we implement directly at 
a low level rather than going through the abstraction of sets and 
relations. An outline of the implementation of partition is given 
in Figure [TT] It uses implementations of Clock T and Event T A 
which are backed by mutable sets to create two new event sources 
yes and no. When an event x arrives at time t, it calls pred on x 
to determine whether to send the event on to yes or to no. Most of 
the effort is in implementing yes. clock and no. clock, and to do 
this we maintain the following data structures: 

• flags is a map from Time to Boolean such that (f, b) £ 
[flags] whenever there is some (t,x) £ [xs. relation] and 
[pred] x = b, 

• prevUnknown is a map from Time to Time such that (t. s) £ 
[[prevUnknown] whenever s —>■ L and either s or l. is not in the 
domain of [[flags], 

• nextUnknown is the inverse of prevUnknown, 

• prevSame is a map from Time to Time such that (l, s ) £ 
[prevSame] whenever s —>* / c t and there is no r —>?/ c s, 

• nextSame is a map from Time to Time such that (s, f) £ 
[prevSame] whenever s — t and there is no t —H/? w, 
and 

• first £ [xs.clock.first], 
where we write: 

• s —¥ (whenever (t,s) £ [xs. clock, prev]. 
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• s —¥},/ c t whenever s —>• t and (s, 6) € [[flags] 9 (t , c), 

• s —¥},/■> t whenever s —¥b/ c t for some c, and 

• s -¥-t/ c t whenever s -9b/c t for some b. 

This data is enough to construct yes. clock and no. clock, for 
example (t, s ) € [yes. clock. prev] whenever: 

One unusual feature of our FRP implementation is that it allows 
out-of-order arrival of events. Due to multithreading, it is possible 
that an event (f, a;) will arrive before an event (u, y) even when 
t > u. For example FrTime m makes use of an ordering scheme 
similar to that of Acar’s (0 self-adjusting computation to ensure in- 
order arrival of events. In our setting, we are prioritizing liveness 
over execution order, and so we only introduce time dependencies 
where they are needed (for example in accum) and allow most event 
sources to proceed at their own pace. 

7. Comparison with push/pull FRP 

The most closely related work is Elliott’s fTOl push-pull FRP. 
Elliott reconstructs the behaviour and event source types using 
futures. Elliott’s type Future A can be encoded in our system as: 

Future A = Not (Not (Time x A )) 
so Elliott’s type for event sources: 

Event A = Future (A x Event A) 
is the equivalent of: 

Event A = Not (Not (Time x Ax Event A)) 
Comparing this to our type: 

Event T A = Not (Not (Time x A)) 

we can see some of the important distinctions between the ap¬ 
proaches: 

• Push-pull FRP is based on the one-shot Future type, rather than 
the implementation of Set using callbacks. 

• In push-pull FRP, events are guaranteed to arrive in order. If 
(. s, x,cr) € p and (t, y. t) 6 cr then s < t. In our implementa¬ 
tion of FRP, events may arrive out-of-order. In particular, push- 
pull FRP uses McCarthy amb to implement union. Out-of-order 
events also occur in Jeltsch’s push-based FRP G2 §4.2.6], 

• Push-pull FRP does not make use of the isomorphism between 
relations and set-valued functions. 

There are also some differences of focus: we have focused on 
liveness, which is not an issue in push-pull FRP, and we have not 
focussed on continuous-time behaviours. 

8. Conclusions and future work 

We have presented a model of FRP which provides liveness guar¬ 
antees by static typing. The implementation of FRP is based on a 
model of sets and relations, which in turn is implemented using 
continuations. This implementation shows how the pull implemen¬ 
tation of behaviours using futures, and the push implementation of 
event sources using the observer pattern, arise naturally. 

There are two areas of future work: on stopping space and time 
leaks and on distribution. 

Currently, there is effort made to ensure that signals do not 
cause space and time leaks, by appropriate use of weak pointers. 
However, it is possible for users to cause a leak by keeping a 
reference to a signal live. We are already tracking time domains, so 


it should be possible to use them as Jeltsch’s tm era parameters, 
and ensure that signals do not have to buffer all their events. 

The Java implementation of the FRP library is already linked 
against a servlet class, to allow it to be used as the processing en¬ 
gine in an HTTP server. It would be interesting to see if HTTP 
could be used as the communication protocol between FRP in¬ 
stances, and so build a distributed FRP implementation. 
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